home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group92c.txt / 000008_icon-group-sender _Mon Oct 5 12:16:43 1992.msg < prev    next >
Internet Message Format  |  1993-01-04  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 5 Oct 1992 14:14:16 MST
  2. Message-Id: <199210051618.AA00842@optima.cs.arizona.edu>
  3. From: keil@apollo.hp.com
  4. Date: Mon, 5 Oct 1992 12:16:43 -0400
  5. In-Reply-To: "Richard L. Goerwitz" <goer@midway.uchicago.edu>
  6.        "storing objects" (Oct  3,  9:13pm)
  7. X-Mailer: Mail User's Shell (7.2.4 2/2/92)
  8. To: "Richard L. Goerwitz" <goer@midway.uchicago.edu>,
  9.         icon-group@cs.arizona.edu
  10. Subject: Re: storing objects
  11. Status: R
  12. Errors-To: icon-group-errors@cs.arizona.edu
  13.  
  14.  
  15. >Let's say that I have a large table that I want to store and recreate
  16. >at run-time in a program.  What is the best way of doing this?  What
  17. >I mean by "best" is primarily "fastest," and not "smallest."
  18. >Any better ideas?
  19. >-Richard
  20.  
  21.  What is large? 1k, 10k, 100k elements?
  22.  With the old scheme of non-expandable tables, I found that increasing
  23.  the initial table size had a big effect for tables of over a thousand
  24.  elements. I'm not sure where the breakover point is for the newer
  25.  expandable table mechanism, but I suspect that if you make the initial
  26.  table size at least as big as, if not twice that size of, your table,
  27.  that things will go faster. At one point, back in the version sevens,
  28.  I added a second parameter to table [table(x,size)] to set the initial
  29.  size of the tablas needed. This seemed more elegant that just always using
  30.  a larger table. On the other hand, with virtual memory systems,
  31.  You may not care if the initial table size is always 10k elememts (if you
  32.  decide to just staticly increase the initial allocation size.)
  33.  
  34. -Mark
  35.